1. Field of the Invention
The present invention relates to an information system for an e-commerce application. More particularly, the invention relates to an object-oriented system and method which uses a shadowing object for approval control.
2. Description of the Related Art
Information systems are becoming vital parts in our daily life, and it is very important to use the information system to control who can perform what operation on what information at what time. Business-to-business (B2B) transactions usually involve large amount of goods and money transfer. However, approval for these transactions is often performed in manual manner. Therefore, it is necessary to enable the transactions (place order, make contract, create RFQ, choose bid winner, do financial transactions among banks, etc.) to be approved by designated approvers using an information system for e-commerce depending on some predetermined rules.
In the field of access control, a number of patents already exist, such as U.S. Pat. No. 5,911,143 and U.S. Pat. No. 6,085,191. Each of the systems has some kind of access control mechanism, but all of them exercise the control before allowing the user to do the operations. These controls are based on the role of the user and the name of the operations. Once allowed, the user is free to do the operations.
Another aspect of the control is based on the result of the operation. That is, a decision to approve or reject is based on the content of the result. This is usually called approval control. Because of the complexity and diversity of the criteria to judge the results, most information systems add special approval codes to the business operation codes for approval control. A number of patents also address how to check and approve results, such as U.S. Pat. No. 5,963,641, and U.S. Pat. No. 6,269,344B1. In these cases, the codes that do actual business operations on the information and the codes that display, analyze and approve the result of the operation are mixed.
In today's rapidly-developing business environment, the approval and its criterion often change. For example, it is possible for an organization to have different rules to decide which purchase order needs to be approved according to different financial situations. For another example, a student's enrolling in a course is usually controlled by a system based on the capacity of the classroom, however, the professor conducting the course also can approve or reject the student's enrolling request.
Thus, in the prior art with the business operation code and the approval code mixed, it is difficult to change the approval rule and process without affecting business logic, and vice versa. That is to say, it is impossible to enable the business operation that was not designed approvable to become approvable, and it is very costly and impractical to make all the business operations approvable.
In various business systems, there exist diverse requirements of approval. Up to now, most e-commerce systems use hard codes to implement approval control. Since the approval request in an enterprise often changes with time and the situation, it is difficult to implement a flexible system to meet all approval requests. Usually some offline manual approval processing is needed in such an existing system, which may cause slow response to the customers and incomplete information in the system.
Websphere Commerce Suite (WCS) a product of IBM corporation, is a tool for building e-commerce applications.
WCS Marketplace edition (MPe) version 4.x implemented a simple approval framework for the WCS version 4.1 programming model. But the command developers have to divide the code for the execution logic into six separate methods, which include pre-approval, post-approval, pre-reject, post-reject, pre-cancel and post-cancel methods. When an action needs approval, the system will call the pre-approval method to prepare, then the approver can view the intermediate result. If the approver decides to approve, then the system will execute the post-approval method to finalize the data.
Though the above method has some capabilities that allow the developer to build approvable commands, this approach has some disadvantages caused by the division of one business operation into several method calls. There are two most significant disadvantages. First, improper method division causes system defects, among which many defects can be found in complete function and performance test, or when the system is being modified, which are not likely to happen in systems with only a small number of new commands, i.e., these defects are not easily corrected. Second, the approval logic can not be separated from business logic, without which such works as flexible development can not be conducted and the performance of the system is difficult to enhance. Of course, there are other disadvantages, such as complicated access control, dead lock, difficult to implement approval variations (multi-level, delegation, batch), etc.
The command developer using WCS commands needs to be very careful in deciding what goes into each respective method. The commands in WCS are to be extended by site developers for particular business requirements. However, dividing commands for approval make such extension more difficult and error prone.